Zap time

The zap time is the total duration from the time viewer presses the channel change button, to the point the picture of the new channel is displayed, along with corresponding audio. These kind of delays exist in all television systems, but they are greater in digital television and systems that use the Internet like IPTV. Human interaction with the system is completely ignored in these measurements, so zap time is not the same as channel surfing.

Zap time can be very disturbing for the viewer since it has to wait too much time when decides to switch the channel. For this reason, zap time is an IPTV feature that has to be reduced in an IPTV system.^[1]

Contents 1 Factors 1.1 Network factors 1.2 MPEG Acquisition 1.3 Set Top Box Buffering/Decode 2 Computing zap time 3 Examples 4 References 5 External links

Factors

The delays in the TV channel change can be caused by different factors. They can be classified according to the systems that cause them. Consequently there are network factors, MPEG acquisition factors and Set Top Box Buffering/Decode.^[2]

Network factors

• Access network latency (processing/propagation delays)

1. STB – IGMP Leave channel X, Join Y
2. DSLAM – Stop X, Start Y
3. DSL FEC/Interleave
4. IGMP features used (version, fast leave, snooping, etc.)
5. Availability of the channel (Channel replication point)

• Core/Aggregation network latency

1. Multicast routing mechanisms used
2. Availability of the channel (Channel replication point)

Actually, these are only a small component of delay in the final time. Usually they take about 50 - 200 ms of the overall zap time. Network quality of service(QoS) can reduce these time ensuring minimal jitter, latency and packet drop.

MPEG Acquisition

• Analyze data to locate MPEG Program Specific Information

1. Wait for and parse PAT
2. Wait for and parse PMT

• Obtain conditional access keys (ECMs) to decrypt channel: wait for ECMs – part of PMT – 100ms to 500ms

• Obtain MPEG key frame

1. I-frame (MPEG2) or IDR frame (H.264)
2. One Index frame per group of pictures (GOP) – 12 to 30 (IBP) frames
3. Typical frequency of I-frame – 500ms.
4. Long GOP structure (2–4 seconds) saves bandwidth, but can causes significant channel change latency

Set Top Box Buffering/Decode

• MPEG Buffer: Encoder buffer fullness model (typical latency – 750ms to 2s). Wait until the buffer is full

• Decode/Display delay (typically about 50 ms)

Computing zap time

The factors that has been explained in the last section don't affect in the same way to the overall zap time. So in the table below there are an example of the zap time in IPTV DSL:

	Channel Change Latency Factor	Device/Location	Typical Latency	Cumulative Latency
1	Send IGMP Leave for channel X	STB	< 10 ms
2	Send IGMP Join for channel Y	STB	< 10 ms
3	DSLAM gets Leave for channel X	DSLAM/Network	< 10 ms
4	DSLAM gets Join for channel Y	DSLAM/Network	< 10 ms	~ 20 - 40 ms
5	DSLAM stops channel X, and sends Channel Y	DSLAM/Network	~ 30 – 50 ms	~ 50 – 90 ms
6	DSL Latency (FEC/Interleave)	DSLAM/Network	~ 10 ms	~ 60 - 100 ms
7	Core/Agg Network Latency	Router/Network	~ 20 – 60ms	~ 80 – 160ms
8	De-jitter buffer	STB	~ 300 ms	~ 380 - 460 ms
9	Wait for PAT/PMT	STB MPEG buffer	~ 125 ms	~ 500 - 580 ms
10	Wait for ECM/CA	STB MPEG buffer	~ 125 ms	~ 620 - 700 ms
11	Wait for I-frame	STB MPEG buffer	~ 250 ms to 2s	~ 870 ms – 2.7s
12	MPEG buffer	STB MPEG buffer	~ 1s to 2s	~ 1.8s – 4.7s
13	Decode	STB	~ 50ms	~ 1.9s – 4.8s

Examples

In this section some typical values of zap time are shown. Actually, in IPTV television these delays are greater than in other technologies:

• Analog (Cable) ~ 1s
• Analog (off-air) ~ 1 – 3s
• MPEG2 over QAM ~ 1.2 – 3s
• MPEG2 over QPSK ~ 2 – 4s
• MPEG2 over IP Multicast ~ 1.5 – 3.5s
• H.264 over IP Multicast ~ 1.7 – 4s

References

External links

• IPTV Industry
• ITU IPTV Focus Group
• ITU-T. Zap time.